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DETAILED ACTION 

Claim Rejections - 35 USC § 102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

2. Claims 1, 2, 8-10, 12-16, 20 and 26 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Packer (US 6,046,980). 

Regarding claim 1, Packer discloses in Fig 1 D, a TCP/IP suite that facilitate 
classification of data flows comprising monitoring a data flow associated with a host relative to 
at least one behavioral attribute [monitor network status parameters, see col. 9, lines 19-20]; 
comparing the least one behavioral attribute observed in the monitoring step to a knowledge base 
of at least one know application behavior pattern [checks each level of the classification tree, 
matches the attributes of a given traffic class if the flow being classified matches attributes of a 
given traffic class, see col. 11, lines 55-58 and Fig. 3; classifier 304]; and classifying the data 
flow based on the comparing step [the class at the level that matches determines the policy for 
the flow being classified, see col. 11, lines 62-63]. 

Regarding claim 2, Packer discloses a method wherein at least one behavioral attribute is 
packet size of the first packet in the data flow [see col. 12, Table 2, IP address includes the 
packet size]. 
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Regarding claim 8, Packer discloses a method wherein at least one behavioral attribute is 
the timing of the data flow relative to at least one similar data flow associated with the host 
[determining a data link rate and latency period from an exchange of packet(s) between TCP 
endpoints, see Fig. IE; where Tdatal is the arrival time of first data packet and Tbase is the 
reference time, see col. 10, lines 32,42]. 

Regarding claim 9, Packer discloses a method wherein at least one behavioral attribute is 
the number of related data flows associated with the host [The initial data packets are examined 
as they establish a connection. Parameters are developed from which RTT and Max data rate 
can be determined, see col. 10, lines 22-24]. 

Regarding claim 10, Packer discloses a method wherein at least one behavioral attribute 
is the timing between at least two packets in the data flow [determining a data link rate and 
latency period from an exchange of packet(s) between TCP endpoints, see Fig. IE; where Tdatal 
is the arrival time of first data packet and Tbase is the reference time, see col. 10, lines 32,42]. 

Regarding claims 12 and 13, Packer discloses a method wherein at least one behavioral 
attribute is timing and sequence of protocol flags contained in packets of the data flow [The SYN 
packets takes a finite but unknown transit time to arrive at the local TCP endpoint, where the 
local TCP endpoint responds with its own SYN packet (packet is of known length, issued at a 
know time, see col. 10, lines 37.40 and Fig. IE; HTTP request from server to client]. 

Regarding claim 14, Packer discloses a method wherein the application behavior pattern 
comprises at least one instance of any one of the following: packet size pattern [see col. 12, 
Table 2, IP address includes the packet size], a threshold information density value, a threshold 
inter-flow timing value [values are obtained for serialization of n, the size of the SYN packet in 
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response and the size of the ACK packet, see col. 10, lines 61-63], or a threshold number of 
related application data flows [TCP autobaud component 302 determines values for selectable 
information such as flow data rate, see col. 15, lines 24-25]. 

Regarding claim 15, Packer discloses a method wherein the application behavior pattern 
characterizes the first group of packets of a data flow associated with a traffic class [a traffic 
specification of a child node, such as FTP node 206 is compared with a flow specification of the 
new flow 300, if a match is discovered the processing in flowchart 51 1 is applied to the child 
node recursively (same traffic class), see col. 18, lines 9-13. If no policy exists, processing 
backtracks to a parent node and looks for a policy associated with the parent node to apply to the 
new flow, see col. 18, lines 21-23]. 

Regarding claim 16, Packer discloses a method wherein the application behavior pattern 
characterizes the first group of packets of a data flow associated with a traffic class Jail traffic 
which does not match any user specified traffic class falls into an automatically created default 
traffic class, which has a default policy, see col. 12, lines 66-68] and wherein the first group of 
packets are characterized in relation to at least one instance of any one of the following: a packet 
size pattern [web traffic may have a service level defined for html (small files) and a separate 
traffic class for gif files (reserved service for larger files), see col. 13, lines30-33], a threshold 
information density value, a threshold inter-flow timing value, or a threshold number of related 
application data flows [determining an acceptable allocation of bandwidth to reserved service 
flows, i.e., GIR or EIR, by allocating rate for each gear 410 or 41 1, based upon individual flow 
demands, base limits and total limits, see col. 18, lines 29-33]. 
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Regarding claim 20, Packer discloses a method wherein monitoring the data flows 
associated with a host relative to at least one application behavior model corresponding to a 
traffic class [bandwidth resource needs of multiple requesting flows are reconciled in accordance 
with policy of each flow based upon the flow's class, see col. 4, lines 10-12]; matching at least 
one of the data flows associated with the host to a traffic class if a threshold number of the data 
flows match a corresponding application behavior model [available bandwidth may be allocated 
among flows, according to policy (and by priority) which may include any combination of GIR 
or EIR, see col. 4, lines 5-8]. 

Regarding claim 26, Packer teaches of a method comprising detecting a data flow in 
network traffic traversing a communications path, the data flows each comprising at least one 
packet [Fig IB; initiating a new flow between client and server with data objects sent to and 
from the network]; parsing explicit attributes at least one packet associated with the data flow 
into a flow specification [a bandwidth manager 306 uses the policy determined by classifier 304 
1 n order to allocate bandwidth according to the service level prescribed by the policy, see col. 
15, lines 33-35], matching the flow specification to a first plurality of traffic classes, wherein the 
first plurality of traffic classes are each defined by one or more matching attributes [Fig 2A and 
2B; data flow assigned to TCP data flow specification, with other matching attributes such as 
bandwidth allocation for FTP or Web files], having found a matching traffic class in the 
matching step, associating the flow specification corresponding to the data flow with a traffic 
class from the first plurality of traffic classes [see Fig 2E and 5F, where data flow is assigned to 
the a specification tree and subsequently assigned to root policy or a recursive child policy in the 
tree], not having found a matching traffic class in the first plurality of traffic classes matching the 
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data flow to at least one additional traffic class, the additional traffic class defined by an 
application behavior pattern [all traffic which does not match any user specified traffic class falls 
into an automatically created default traffic class, which has a default policy, see col. 12, lines 
66-68], the application behavior pattern comprising comprises at least one instance of: a packet 
size pattern [web traffic may have a service level defined for html (small files) and a separate 
traffic class for gif files (reserved service for larger files), see col. 13, lines30-33], a threshold 
information density value, a threshold inter-flow timing value [values are obtained for 
serialization of n, the size of the SYN packet in response and the size of the ACK packet, see col. 
10, lines 61-63], or a threshold number of related application data flows [determining an 
acceptable allocation of bandwidth to reserved service flows, i.e., GIR or EIR, by allocating rate 
for each gear 410 or 41 1, based upon individual flow demands, base limits and total limits, see 
col. 18, lines 29-33]. 

3. Claim 17 are rejected under 35 U.S.C. 102(b) as being anticipated by Aimoto et al. (US 
6,144,636), hereinafter referred to as Aimoto. 

Regarding claim 17, Aimoto discloses in the abstract, a method wherein modeling the 
behavior of a network application to generate an application behavior pattern [an input packet 
from the input port is delivered to at least one output 'port in accordance with address 
information of the input packet and connection information having been set (configured) at the 
time of setting the connection between the transmission source and destination]; and configuring 
a network traffic monitoring device to classify data flows against the application behavior pattern 
[an ABR congestion control function for a switch of shared buffer construction (classes) in 
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which a cell buffer is shared by a plurality of ports bandwidth, see col. 18, lines 61-63, wherein 
the ABR traffic class, a bandwidth management cell periodically transmits predetermined 
number of data cells, see col. 2, lines 10-1 1]; wherein the application behavior pattern comprises 
at least one instance of any one of the following: a packet size pattern [a Constant Bit Rate traffic 
class in which a fixed amount of bandwidth is continuously made available by the network to 
transfer cells, see col. 1, lines53-55], a threshold information density value [information on a 
threshold value (information density) for each traffic class are held within the packet switch, see 
col. 3, lines 18-20], a threshold inter-flow timing value, or a threshold number of related 
application data flows [a table having plurality of entries which illustrates behavior of congestion 
notification, see col. 17, lines 46-47]. 

4. Claims 29-33 are rejected under 35 U.S.C. 102(b) as being anticipated by Bennett (US 
6,122,670). 

Regarding claim 29, Bennett discloses a method comprising detecting a data flow in 
network traffic traversing a communication path, the data flow comprising at least one packet 
[nodes interconnected to form several hosts of WAN/LAN networks (Fig.l) where discoverable 
protocol is know to be TCP based on the application and FTP sewer (Fig. 2)]; applying a 
mathematical function to at least one packet in the data flow to derive a computer value that 
characterizes entropy of information contained in the at least one packet [IP header checksum - 
hardware calculation - performed on receive packet to reassemble IP datagram or datagram 
fragment to its original structure, col. 6, lines 28-30 and Fig 6]; comparing the computed value to 
at least one traffic class, said traffic class defined, at least in part, by a required computed value 
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[protocol logic subsystem verifies traffic class; IP header and TCP segment checksums before 
sending datagram col. 6, lines 34-37]. 

Regarding claim 30, Bennett discloses a method wherein the required computed value is 
determined by applying the mathematical function to data flows know to be Of the traffic class 
[the header check sum is indicated by the fragment bit flag 301 and offset fragment 302 which 
ensures datagram validity. Based on fragment bits set, the datagram is stored in memory based 
on its relative offset from the beginning of the original datagram or in its own base address in 
memory, see col. 8, lines 34-43]. 

Regarding claim 31, Bennett discloses a method wherein the mathematical function 
computes a value indicating the information density of at least one packet [based on relative 
offsets and partial checksums calculated, other datagrams that are received with identical 
identification filed 333, source and destination IP addresses, they are known to be another 
following fragment of a first fragment, see col. 7, lines 45-50]. 

Regarding claim 32, Bennett discloses a method wherein the required computed value is 
a range of values [the reconfigurable protocol logic has memory recourses for datagram storage, 
and lookup tables for datagram de-fragmentation and other protocol functions, see col. 11, lines 
10-15]. 

Regarding claim 33, Bennett discloses a method comprising detecting a data flow in 
network traffic traversing a communication path, the data flow comprising at least one packet 
containing a first checksum [nodes interconnected to form several hosts of WANILAN networks 
(Fig.l) where discoverable protocol is know to be TCP based on the application and FTP server 
(Fig. 2)]; applying a mathematical function to at least one packet in the data flow to derive a 
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second checksum [IP header checksum - performed on receive packet to reassemble IP datagram 
or datagram fragment to its original structure, col. 6, lines 28-30 and Fig 6]; comparing the 
computed second checksum to the first checksum value contained in at least on packet [protocol 
logic subsystem verifies traffic class; IP header and TCP segment checksums before sending 
datagram col. 6, lines 34-37]; matching the data flow to a traffic class, wherein the traffic class is 
defined at least in part by whether the computed second checksum should match the first 
checksum in the at least one packet [based on relative offsets and partial checksums (TCP/UDP 
protocol) calculated, other datagrams that are received with identical identification filed 333, 
source and destination IP addresses, arc known to be another following fragment of a first 
fragment and subsequently added, see col. 7, lines 45-50]. 

Claim Rejections - 35 USC §103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 3-5 are rejected under 35 U.S.C. 103(a) as being unpatentable over Packer (US 
6,046,980) in view of Bennett (US 6,122,670). 

Regarding claims 3 and 4 as explained in the rejection statement of claim 1, Parker 
discloses all of the claim limitations of claim 1 (parent claim). 

Parker does not disclose of a method wherein at least one behavioral attribute is packet 
size of the first packet in the data flow. 
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However, Bennett teaches of a method where [a memory 40 in a network card 2000, 
stores command lists for disposition queue of datagrams, see col. 6, lines 11-13. When a packet 
is received, network interface 50 reassembles the IP datagram or datagram fragments and then 
writes the corresponding datagram fragments to datagram buffer 53, see col. 6, lines 27-30. 
Where flag 301 and fragment offset 302 together indicate whether datagram 332 is a fragment of 
a larger datagram, see col. 6, lines 65-67]. 

Based on the teachings of Bennett, at the time of the invention, it would have been 
obvious to a person in ordinary skill in the art to incorporate the network card of Bennett in a 
traffic class at any level of the TCP/IP protocol or (traffic classification tree in Fig. 2C), whereby 
configuring a traffic class node that would specify policies by using the flag 301 and fragment 
offset 302 as taught by Bennett to classify dataflow according to n-array, i.e. first, second .... ,nth 
datagram or datagram fragments, see col. 14, lines, Fig. 2C and Fig. 2D. Thus, it would have 
been obvious to one of ordinary skill in the art a the time to be motivated to incorporate the IP 
flag together with a fragment offset as one behavioral attribute to provide the ability to classify 
and search traffic based upon multiple orthogonal classification attributes. 

Regarding claim 5 as explained in the rejection statement of claim 1, Parker discloses all 
of the claim limitations of claim 1 (parent claim). 

Packer does not disclose of a method wherein at least one behavioral attribute is packet 
size of plurality of packets in the data flow. 

However, Bennett teaches of a method where [an IP datagram identifier are checked 
against any other recently received datagrams by a de- fragmentation lookup subsystem. Either a 
new allocation in datagram memory 53 is created for new IP datagram identifiers, or datagram 
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fragments are stored (accumulated) with other fragments from the same IP datagram identifier by 
returning the base address of the memory allocation in 53 where the previously received 
fragment(s) where stored, see col. 13, lines 18-24. The Protocol logic 45 sums the data (IP and 
TCP checksums) and transfers these sums to the accumulation register, see lines 46-48]. 

Based on the teachings of Bennett, at the time of the invention, it would have been 
obvious to a person in ordinary skill in the art to incorporate the network card of Bennett in a 
traffic class at any level of the TCP/IP protocol or (traffic classification tree in Fig. 2C), whereby 
configuring a traffic class node that would specify policies by using the end of the IP header of 
Bennett, as indication of the amount of data having been transferred equaling the value in header 
length field or (packet size). Thus, it would have been obvious to one of ordinary skill in the art a 
the time to be motivated to incorporate the header length as one behavioral attribute to provide 
the ability to classify and search traffic based upon multiple orthogonal classification attributes. 

7. Claims 6 and 7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Packer 
(US 6,046,980) in view of Aimoto (US 6,144,636). 

Regarding claim 6 as explained in the rejection statement of claim 1, Packer discloses all 
of the claim limitations of claim 1 (parent claim). 

Packer does not disclose a method wherein at least one behavioral attribute is the 
information density associated with at least one packet in the data flow. 

Aimoto teaches a technique wherein information on a counter and information on a 
threshold value (information density) for each traffic class are held within the packet switch, see 
col. 3, lines 18-20. 
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It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the packet switch and congestion notification method of Aimoto in the system of 
Packer. One of ordinary skill in the art at the time of the invention would have been motivated to 
do so in order to realize a system for managing flow bandwidth which recognized the congestion 
state of the packet switch to improve system efficiency and quality, as taught by Aimoto (See 
Abstract.) 

Regarding claim 7 as explained in the rejection statement of claim 1 , Packer discloses all 
of the claim limitations of claim 1 (parent claim). 

Packer does not disclose a method wherein at least one behavioral attribute is the 
information density. 

Aimoto teaches information on a counter and information on a threshold value 
(information density) for each traffic class are held within the packet switch, see col. 3, lines 18- 
20, associated with the first packet in the data flow (buffers such as RIRO type input buffers and 
FIFO type out put buffers are included in the packet switch and an input buffer control unit 
determines a cell which is to be delivered, see col. 2, lines 38-41). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the packet switch and congestion notification method of Aimoto in the system of 
Packer. One of ordinary skill in the art at the time of the invention would have been motivated to 
do so in order to realize a system for managing flow bandwidth which recognized the congestion 
state of the packet switch to improve system efficiency and quality, as taught by Aimoto (See 
Abstract.) 
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8. Claims 1 1, 27, and 28 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Packer (US 6,046,980) in view of Bennett (US 6,122,670). 

Regarding claim 1 1 as explained in the rejection statement of claim 1, Packer discloses 
all of the claim limitations of claim 1 (parent claim). 

Packer does not disclose a method wherein at least one behavioral attribute is a sequence 
of protocol flags contained in packets of the data flow. 

Bennett teaches a reconfigurable protocol logic subsystem, coalesces numerous 
operations from the various protocols which speed up the overall system processing, see col. 3, 
lines 50-51 and Fig. 4, protocol logic 45. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Packer. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 27 as explained in the rejection statement of claim 21, Packer discloses 
all of claim limitations of claim 2 1 . 

Packer does not disclose wherein said flow specification contains at least one instance of 
any one of the following: a protocol family designation, a direction of packet flow designation, a 
protocol type designation, a pair of hosts, a pair of ports, a pointer to a MIME type, and a 
pointer to an application specific attribute. 

Bennett teaches an apparatus wherein Flow specification contains at least one instance of 
any one of the following; a protocol family designation [Fig. 2 A; TCP or a UDP process], a 
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direction of packet flow designation, a protocol type designation [see Fig. 18A and 18B, 
processing of incoming TCP segments constitutes a bi-directional flow of data between FTP 
server and FTP client], a protocol type designation [see Fig. 6; source IP address 306 and 
destination IP address 308], a pair of hosts, a pair of ports a pointer to a MIME type, and a 
pointer to an application-specific attribute [commands for both TCP ACK and for a disposition 
queue of pending datagrams; a queue of pointers to datagrams which need to be transferred to the 
network, see col. 6, lines 12-16]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Packer. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 28 as explained in the rejection statement of claim 21, Packer discloses 
all of claim limitations of claim 2 1 . 

Packer does not disclose wherein said flow specification contains, and wherein the one or 
more matching attributes include, at least one instance of any one of the following: a protocol 
family designation, a direction of packet flow designation, a protocol type designation, a pair of 
hosts, a pair of ports, a pointer to a MIME type, and a pointer to an application-specific 
attribute. 

Bennett teaches an apparatus wherein Flow specification contains, and wherein the one or 
more matching attributes include, at least one instance of any one of the following: a protocol 
family designation [Fig.2A; TCP or a UDP process], a direction of packet flow designation [see 
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Fig. 18A and 18B, processing of incoming TCP segments constitutes a bi-directional flow of 
data between FTP server and FTP client], a protocol type designation, a pair of hosts [see Fig. 1; 
nodes interconnected to form several hosts of WAN/LAN networks], a pair of ports [see Fig. 7; 
source port 310 and destination port 3 12], a pointer to a MIME type, and a pointer to an 
application-specific attribute [see Fig. 6, flags 301; fragments of original datagram and fragment 
offset 302; indicates bytes of original datagram length 330]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Packer. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

9. Claims 17-19 and 23-25 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Aimoto (US 6,144,636) in view of Bennett (US 6,122,670). 

Re claim 21, Aimoto discloses in Fig. 1 and abstract of the prior art, an apparatus wherein 
a packet processor (switch 100) operative to detect data flows in network traffic traversing a 
communication path [communication is transferred from terminal A toward terminal B via the 
switch, col. 9, lines 2-26], the data flows each comprising at least one packet (header conversion 
circuit 132 and line input controller 13 3); parse at least one packet associated with a data flow 
into a flow specification [input packet is delivered to at least one output port in accordance with 
address information of the input packet and connection info set in the packet switch at the time 
of connection setup], a traffic classification engine operative to match the data flow to a plurality 
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of traffic classes, at least one of the traffic classes defined by one or more application behavior 
patterns [the marking mode provides at least the following apparatus in the switch for the 
congestion decision/notification circuit; cell number counter information, threshold value for 
every connection a comparator unit is also provided for every connection, connection number 
count, target bandwidth information register, etc. See col. 6, lines 38-46]; having found a 
matching traffic class in the matching step [the results of the comparator circuit in Fig. 5 is 
provided for every connection for deciding whether the value of a cell number counter has 
exceeded a threshold value information of all output ports held in the switch, see col. 6, lines 6- 
8], associate the flow specification corresponding to the data flow with a traffic class from the 
plurality of traffic classes [the bandwidth management cell which contains congestion 
notifications (max. bandwidth for a transmission) inserted by the decision/notification circuit 
decides whether the congestion notification of every connection is to performed in compliance 
with notification of the congested state for all output ports or, whether the congestion notification 
is to be immediately performed, see col. 6, lines 31-35] At least one of the plurality of traffic 
classes is defined by one or more matching attributes [the marking mode provides at least the 
following apparatus in the switch for the congestion decision/notification circuit; cell number 
counter information, threshold value for every connection a comparator unit is also provided for 
every connection, connection number count, target bandwidth information register, etc. See col. 
6, lines 38-46], wherein Said matching attributes are explicitly presented in the packets 
associated with the data flows [each congestion notification includes a binary marking mode (to 
include an explicit rate field, binary marking filed and a maximum rate field) in which the source 
terminal is notified of an allowed transmission, see col. 10, lines 10-14]. 
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Aimoto does not disclose wherein the application behavior patterns each comprise at 
least any one of the following: a packet size pattern, a threshold information density value, a 
threshold inter-flow timing value, or a threshold number of related application data flows, an 
inter-packet timing value, a sequence of protocol flags, or an inter-packet protocol flag timing 
value. 

Bennett teaches a packet size pattern [source port field 310 and destination port field 312, 
see Fig. 7], a threshold information density value, a threshold inter- flow timing value [a buffer 
with command lists for both TCP ACK commands and for disposition queues for pending 
datagrams, sec col. 6, lines 1 1-13], or a threshold number of related application data flows [TCP 
process includes instructions for sending data to FTP client and also receiving data from FTP via 
buffers, see col. 4, lines 50-53 and Fig. 2B], an inter-packet timing value[Datagram ID numbers, 
source IP addresses are passed via means of communication to the de- fragmentation lookup 
subsystem, see col. 9, lines 20-23 and Fig. 9, reconfigurable FPGAs 922 and 924], a sequence of 
protocol flags [see Fig. 4, protocol logic device 45], an inter-packet protocol flag timing value. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Aimoto. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 18 as explained in the rejection statement of claim 17, Aimoto discloses 
all of the claim limitations of claim 17. 
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Aimoto does not disclose a method wherein the application behavior pattern comprises at 
least one instance of any one of the following: a packet size pattern, a threshold information 
density value, a threshold inter- flow timing value, or a threshold number of related application 
data flows, an inter-packet value, a sequence of protocol flags, an inter-packet protocol flag 
timing value. 

Bennett teaches a packet size pattern [source port field 310 and destination port field 312, 
see Fig. 7], a threshold information density value, a threshold inter- flow timing value [a buffer 
with command lists for both TCP ACK commands and for disposition queues for pending 
datagrams, sec col. 6, lines 1 1-13], or a threshold number of related application data flows [TCP 
process includes instructions for sending data to FTP client and also receiving data from FTP via 
buffers, see col. 4, lines 50-53 and Fig. 2B], an inter-packet timing value[Datagram ID numbers, 
source IP addresses are passed via means of communication to the de- fragmentation lookup 
subsystem, see col. 9, lines 20-23 and Fig. 9, reconfigurable FPGAs 922 and 924], a sequence of 
protocol flags [see Fig. 4, protocol logic device 45], an inter-packet protocol flag timing value. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Aimoto. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 19 as explained in the rejection statement of claim 17, Aimoto discloses 
all of the claim limitations of claim 17. 

Aimoto does not disclose wherein the protocol flags are TCP protocol flags. 
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Bennett teaches in Fig. 1, a TCP/IP protocol stack. The protocol flags are TCP protocol 
flags [TCP process includes instructions for sending data to FTP client and also receiving data 
from FTP via buffers, see col. 4, lines 50-53 and Fig. 2B]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Aimoto. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 23 as explained in the rejection statement of claim 21, Aimoto discloses 
all of claim limitations of claim 21. 

Aimoto does not disclose wherein said flow specification contains at least one instance of 
any one of the following: a protocol family designation, a direction of packet flow designation, a 
protocol type designation, a pair of hosts, a pair of ports, a pointer to a MIME type, and a 
pointer to an application specific attribute. 

Bennett teaches an apparatus wherein Flow specification contains at least one instance of 
any one of the following; a protocol family designation [Fig. 2 A; TCP or a UDP process], a 
direction of packet flow designation, a protocol type designation [see Fig. 18A and 18B, 
processing of incoming TCP segments constitutes a bi-directional flow of data between FTP 
server and FTP client], a protocol type designation [see Fig. 6; source IP address 306 and 
destination IP address 308], a pair of hosts, a pair of ports a pointer to a MIME type, and a 
pointer to an application-specific attribute [commands for both TCP ACK and for a disposition 
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queue of pending datagrams; a queue of pointers to datagrams which need to be transferred to the 
network, see col. 6, lines 12-16]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Aimoto. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 24 as explained in the rejection statement of claim 21, Aimoto discloses 
all of claim limitations of claim 2 1 . 

Aimoto does not disclose wherein said flow specification contains, and wherein the one 
or more matching attributes include, at least one instance of any one of the following: a protocol 
family designation, a direction of packet flow designation, a protocol type designation, a pair of 
hosts, a pair of ports, a pointer to a MIME type, and a pointer to an application-specific 
attribute. 

Bennett teaches an apparatus wherein Flow specification contains, and wherein the one or 
more matching attributes include, at least one instance of any one of the following: a protocol 
family designation [Fig.2A; TCP or a UDP process], a direction of packet flow designation [see 
Fig. 18A and 18B, processing of incoming TCP segments constitutes a bi-directional flow of 
data between FTP server and FTP client], a protocol type designation, a pair of hosts [see Fig. 1; 
nodes interconnected to form several hosts of WAN/LAN networks], a pair of ports [see Fig. 7; 
source port 310 and destination port 312], a pointer to a MIME type, and a pointer to an 
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application-specific attribute [see Fig. 6, flags 301; fragments of original datagram and fragment 
offset 302; indicates bytes of original datagram length 330]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the method of sending and receiving data of Bennett in the system of Aimoto. One 
of ordinary skill in the art at the time of the invention would have been motivated to do so in 
order to realize a system capable of recognizing TCP protocol, as taught by Bennett (See 
Abstract.) 

Regarding claim 25, the primary reference further teaches at least one of the plurality of 
traffic classes is defined by one or more matching attributes [the marking mode provides at least 
the following apparatus in the switch for the congestion decision/notification circuit; cell number 
counter information, threshold value for every connection a comparator unit is also provided for 
every connection, connection number count, target bandwidth information register, etc. See col. 
6, lines 38-46], wherein said matching attributes are explicitly presented in the packets 
associated with the data flows [each congestion notification includes a binary marking mode (to 
include an explicit rate field, binary marking filed and a maximum rate field) in which the source 
terminal is notified of an allowed transmission, see col. 10, lines 10-14]. 

Response to Arguments 

10. Applicant's arguments with respect to claims 1-21 and 23-33 have been considered but 
are moot in view of the new ground(s) of rejection. 

On page 14 of the remarks, regarding claims 1, 17, 21, and 26, the Applicant argues the 
primary reference does not teach the claim invention. The Examiner respectfully disagrees. The 
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Applicant appears to be reading limitations from the specification into the claims, which is 
inappropriate. For example, "behavior pattern" is a broad term without any structural or 
functional limitations. The Examiner's interpretation is both reasonable and fair. Therefore, 
based upon the Examiner's interpretation of the claim limitations, as stated in the rejection, the 
claimed invention is taught. 



Conclusion 

1 1 . Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to DONALD L. MILLS whose telephone number is (571)272-3094. 
The examiner can normally be reached on 9:00 AM to 5:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chi Pham can be reached on 571-272-3179. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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